home *** CD-ROM | disk | FTP | other *** search
/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / documents / RFC / rfc1466.txt < prev    next >
Text File  |  1994-08-01  |  22KB  |  563 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          E. Gerich
  8. Request for Comments: 1466                                         Merit
  9. Obsoletes: 1366                                                 May 1993
  10.  
  11.  
  12.              Guidelines for Management of IP Address Space
  13.  
  14. Status of this Memo
  15.  
  16.    This memo provides information for the Internet community.  It does
  17.    not specify an Internet standard.  Distribution of this memo is
  18.    unlimited.
  19.  
  20. Abstract
  21.  
  22.    This document has been reviewed by the Federal Engineering Planning
  23.    Group (FEPG) on behalf of the Federal Networking Council (FNC), the
  24.    co-chairs of the Intercontinental Engineering Planning Group (IEPG),
  25.    and the Reseaux IP Europeens (RIPE).  There was general consensus by
  26.    those groups to support the recommendations proposed in this document
  27.    for management of the IP address space.
  28.  
  29. 1.0  Introduction
  30.  
  31.    With the growth of the Internet and its increasing globalization,
  32.    much thought has been given to the evolution of the network number
  33.    allocation and assignment process. RFC 1174, "Identifier Assignment
  34.    and Connected Status", [1] dated August 1990 recommends that the
  35.    Internet Registry (IR) continue as the principal registry for network
  36.    numbers; however, the IR may allocate blocks of network numbers and
  37.    the assignment of those numbers to qualified organizations.  The IR
  38.    will serve as the default registry in cases where no delegated
  39.    registration authority has been identified.
  40.  
  41.    The distribution of the registration function is desirable, and in
  42.    keeping with that goal, it is necessary to develop a plan which
  43.    manages the distribution of the network number space.  The demand for
  44.    network numbers has grown significantly within the last two years and
  45.    as a result the allocation of network numbers must be approached in a
  46.    more systematic fashion.
  47.  
  48.    This document proposes a plan which will forward the implementation
  49.    of RFC 1174 and which defines the allocation and assignment of the
  50.    network number space.  There are three major topics to be addressed:
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Gerich                                                          [Page 1]
  59.  
  60. RFC 1466     Guidelines for Management of IP Address Space      May 1993
  61.  
  62.  
  63.       1) Qualifications for Distributed Regional Registries
  64.  
  65.       2) Allocation of the Network Number Space by the Internet Registry
  66.  
  67.       3) Assignment of the Network Numbers
  68.  
  69. 2.0  Qualifications for Distributed Regional Registries
  70.  
  71.    The major reason to distribute the registration function is that the
  72.    Internet serves a more diverse global population than it did at its
  73.    inception.  This means that registries which are located in distinct
  74.    geographic areas may be better able to serve the local community in
  75.    terms of language and local customs. While there appears to be wide
  76.    support for the concept of distribution of the registration function,
  77.    it is important to define how the candidate delegated registries will
  78.    be chosen and from which geographic areas.
  79.  
  80.    Based on the growth and the maturity of the Internet in Europe, North
  81.    America, Central/South America and the Pacific Rim areas, it is
  82.    desirable to consider delegating the registration function to an
  83.    organization in each of those geographic areas.  Until an
  84.    organization is identified in those regions, the IR will continue to
  85.    serve as the default registry.  The IR remains the root registry and
  86.    continues to provide the registration function to all those regions
  87.    not covered by distributed regional registries.  And as other regions
  88.    of the world become more and more active in the Internet, the
  89.    Internet Assigned Numbers Authority (IANA) and the IR may choose to
  90.    look for candidate registries to serve the populations in those
  91.    geographic regions.
  92.  
  93.    It is important that the regional registry is unbiased and and widely
  94.    recognized by network providers and subscribers within the geographic
  95.    region.  It is also important that there is just a single regional
  96.    registry per geographical region at this level to provide for
  97.    efficient and fair sub-allocation of the address space.  To be
  98.    selected as a distributed regional registry an organization should
  99.    meet the following criteria:
  100.  
  101.       a) networking authorities within the geographic area
  102.          legitimize the organization,
  103.  
  104.       b) the organization is well-established and has
  105.          legitimacy outside of the registry function,
  106.  
  107.       c) the organization will commit appropriate resources to
  108.          provide stable, timely, and reliable service
  109.          to the geographic region,
  110.  
  111.  
  112.  
  113.  
  114. Gerich                                                          [Page 2]
  115.  
  116. RFC 1466     Guidelines for Management of IP Address Space      May 1993
  117.  
  118.  
  119.       d) is committed to allocate IP numbers according to
  120.          the guidelines established by the IANA and the IR, and
  121.  
  122.       e) is committed to coordinate with the IR to establish
  123.          qualifications and strategies for sub-allocations of
  124.          the regional allocation.
  125.  
  126.    The distributed regional registry is empowered by the IANA and the IR
  127.    to provide the network number registration function to a geographic
  128.    area.  It is possible for network applicants to contact the IR
  129.    directly.  Depending on the circumstances the network subscriber may
  130.    be referred to the regional registry, but the IR will be prepared to
  131.    service any network subscriber if necessary.
  132.  
  133. 3.0  Allocation of the Network Number Space by the Internet Registry
  134.  
  135.    The Class A portion of the number space represents 50% of the total
  136.    IP host addresses; Class B is 25% of the total; Class C is
  137.    approximately 12% of the total.  Table 1 shows the current allocation
  138.    of the IP network numbers.
  139.  
  140.                    Total           Allocated         Allocated (%)
  141.    Class A           126               49              38%
  142.    Class B         16383             7354              45%
  143.    Class C       2097151            44014               2%
  144.  
  145.              Table 1: Network Number Statistics (May 1992) [2]
  146.  
  147.    Class A and B network numbers are a limited resource and therefore
  148.    allocations from this space will be restricted.  The entire Class A
  149.    number space will be retained by the IANA and the IR.  No allocations
  150.    from the Class A network numbers will be made to distributed regional
  151.    registries at this time. (See section 4.1.)
  152.  
  153.    Allocations from the Class B network number space will be restricted
  154.    also.  Small blocks of numbers may be allocated to regional
  155.    registries, which will be required to ensure that the allocation
  156.    guidelines are met. The IR will monitor those allocations. (See
  157.    section 4.2.)
  158.  
  159.    It is proposed that the IR, and any designated regional registries,
  160.    allocate addresses in conformance with this overall scheme. Where
  161.    there are qualifying regional registries established, primary
  162.    responsibility for allocation within that block will be delegated to
  163.    that registry. It should be noted that the Reseaux IP Europeens
  164.    Network Coordination Center (RIPE NCC) had been allocated a block of
  165.    Class C addresses (193.0.0 - 193.255.255) prior to the adoption of
  166.    this proposal. The RIPE NCC has agreed to allocate the addresses
  167.  
  168.  
  169.  
  170. Gerich                                                          [Page 3]
  171.  
  172. RFC 1466     Guidelines for Management of IP Address Space      May 1993
  173.  
  174.  
  175.    within that block according to the guidelines stated in this RFC.
  176.  
  177.    The Class C network number space will be divided into allocatable
  178.    blocks which will be reserved by the IANA and IR for allocation to
  179.    distributed regional registries.  In the absence of designated
  180.    regional registries in geographic areas, the IR will assign addresses
  181.    to networks within those geographic areas according to the Class C
  182.    allocation divisions.
  183.  
  184.    Inspection of the Class C IP network numbers shows that the number
  185.    space with prefixes 192 and 193 are assigned.  The remaining space
  186.    from prefix 194 through 223 is mostly unassigned.
  187.  
  188.    The IANA and the IR will reserve the upper half of this space which
  189.    corresponds to the IP address range of 208.0.0.0 through
  190.    223.255.255.255. Network numbers from this portion of the Class C
  191.    space will remain unallocated and unassigned until further notice.
  192.  
  193.    The remaining Class C network number space will be allocated in a
  194.    fashion which is compatible with potential address aggregation
  195.    techniques. It is intended to divide this address range into eight
  196.    equally sized address blocks.
  197.  
  198.       192.0.0.0 - 193.255.255.255
  199.       194.0.0.0 - 195.255.255.255
  200.       196.0.0.0 - 197.255.255.255
  201.       198.0.0.0 - 199.255.255.255
  202.       200.0.0.0 - 201.255.255.255
  203.       202.0.0.0 - 203.255.255.255
  204.       204.0.0.0 - 205.255.255.255
  205.       206.0.0.0 - 207.255.255.255
  206.  
  207.    Each block represents 131,072 addresses or approximately 6% of the
  208.    total Class C address space.
  209.  
  210.    It is proposed that a broad geographic allocation be used for these
  211.    blocks.  At present there are four major areas of address allocation:
  212.    Europe, North America, Pacific Rim, and South & Central America.
  213.  
  214.    In particular, the top level block allocation be designated as
  215.    follows:
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Gerich                                                          [Page 4]
  227.  
  228. RFC 1466     Guidelines for Management of IP Address Space      May 1993
  229.  
  230.  
  231.    Multi-regional          192.0.0.0 - 193.255.255.255
  232.    Europe                  194.0.0.0 - 195.255.255.255
  233.    Others                  196.0.0.0 - 197.255.255.255
  234.    North America           198.0.0.0 - 199.255.255.255
  235.    Central/South
  236.     America                200.0.0.0 - 201.255.255.255
  237.    Pacific Rim             202.0.0.0 - 203.255.255.255
  238.    Others                  204.0.0.0 - 205.255.255.255
  239.    Others                  206.0.0.0 - 207.255.255.255
  240.  
  241.    It is proposed that the IR, and any designated regional registries,
  242.    allocate addresses in conformance with this overall scheme.  Where
  243.    there are qualifying regional registries established, primary
  244.    responsibility for allocation from within that block will be
  245.    delegated to that registry.
  246.  
  247.    The ranges designated as "Others" permit flexibility in network
  248.    number assignments which are outside of the geographical regions
  249.    already allocated.  The range listed as multi-regional represents
  250.    network numbers which have been assigned prior to the implementation
  251.    of this plan.  It is proposed that the IANA and the IR will adopt
  252.    these divisions of the Class C network number space and will begin
  253.    assigning network numbers accordingly.
  254.  
  255. 4.0  Assignment of the Network Number Space
  256.  
  257.    The exhaustion of the IP address space is a topic of concern for the
  258.    entire Internet community. This plan for the assignment of Class A,
  259.    B, or C IP numbers to network applicants has two major goals:
  260.  
  261.       1) to reserve a portion of the IP number space so that it may be
  262.       available to transition to a new numbering plan
  263.  
  264.       2) to assign the Class C network number space in a fashion which
  265.       is compatible with proposed address aggregation techniques
  266.  
  267. 4.1  Class A
  268.  
  269.    The Class A number space can support the largest number of unique
  270.    host identifier addresses and is also the class of network numbers
  271.    most sparsely populated.  There are only approximately 11 Class A
  272.    network numbers which are unassigned or unreserved, and these 11
  273.    network numbers represent about 9% of the total address space.
  274.  
  275.    The IANA and the IR will retain sole responsibility for the
  276.    assignment of Class A network numbers. The upper half of the Class A
  277.    number space will be reserved indefinitely (IP network addresses
  278.    64.0.0.0 through 127.0.0.0).  While it is expected that no new
  279.  
  280.  
  281.  
  282. Gerich                                                          [Page 5]
  283.  
  284. RFC 1466     Guidelines for Management of IP Address Space      May 1993
  285.  
  286.  
  287.    assignments of Class A numbers will take place in the near future,
  288.    any organization petitioning the IR for a Class A network number will
  289.    be expected to provide a detailed technical justification documenting
  290.    network size and structure. Class A assignments are at the IANA's
  291.    discretion.
  292.  
  293. 4.2  Class B
  294.  
  295.    Previously, organizations were recommended to use a subnetted Class B
  296.    network number rather than multiple Class C network numbers.  Due to
  297.    the scarcity of Class B network numbers and the underutilization of
  298.    the Class B number space by most organizations, the recommendation is
  299.    now to use multiple Class Cs where practical.
  300.  
  301.    The restrictions in allocation of Class B network numbers may cause
  302.    some organizations to expend additional resources to utilize multiple
  303.    Class C numbers. This is unfortunate, but inevitable if we implement
  304.    strategies to control the assignment of Class B addresses.  The
  305.    intent of these guidelines is to balance these costs for the greater
  306.    good of the Internet.
  307.  
  308. 4.2.1
  309.  
  310.    Organizations applying for a Class B network number should fulfill
  311.    the following criteria:
  312.  
  313.       1)  the organization presents a subnetting plan which documents
  314.           more than 32 subnets within its organizational network
  315.  
  316.       AND
  317.  
  318.       2)  the organization has more than 4096 hosts
  319.  
  320.    Organizations applying for a Class B network number must submit an
  321.    engineering plan that documents its need for a Class B network
  322.    number.  This document must demonstrate that it is unreasonable to
  323.    engineer its network with a block of class C network numbers.  The
  324.    engineering plan must include how many hosts the network will have
  325.    within the next 24 months and how many hosts per subnet within the
  326.    next 24 months.
  327.  
  328.    The submitted engineering plans will be held in strict confidence by
  329.    the Internet registries and will only be used to judge whether an
  330.    application is justified. If it is deemed that the applicant's
  331.    engineering plan, including the number of hosts and subnets, does not
  332.    warrant a Class B assignment, the applicant will be allocated a block
  333.    of Class C addresses.
  334.  
  335.  
  336.  
  337.  
  338. Gerich                                                          [Page 6]
  339.  
  340. RFC 1466     Guidelines for Management of IP Address Space      May 1993
  341.  
  342.  
  343.    There may be some circumstances where the organization is unable to
  344.    utilize a block of Class C network numbers and does not meet the
  345.    suggested criteria.  In such cases, the engineering plan should
  346.    clearly demonstrate their inability to utilize a block of Class C
  347.    network numbers.
  348.  
  349. 4.2.2
  350.  
  351.    The IR may allocate small blocks of Class B network numbers to
  352.    regional registries if so doing will improve the service that is
  353.    being provided to the community.  The IR may issue more specific
  354.    guidelines for the further assignment of the numbers which will be
  355.    consistent with the stated guidelines.  The IR may require accounting
  356.    of the block assignment including receipt of the applicants'
  357.    engineering plans.  The IR may audit these engineering plans to
  358.    confirm that the assignments are consistent with the guidelines.
  359.  
  360. 4.3  Class C
  361.  
  362.    Section 3 of this document recommends a division of the Class C
  363.    number space.  That division is primarily an administrative division
  364.    which lays the groundwork for distributed network number registries.
  365.    This section addresses assignment of network numbers from within
  366.    regional block assignments. Sub-allocations of the block to sub-
  367.    registries is beyond the scope of this paper.
  368.  
  369.    By default, if an organization requires more than a single Class C,
  370.    it will be assigned a bit-wise contiguous block from the Class C
  371.    space allocated for its geographic region.
  372.  
  373.    For instance, an European organization which requires fewer than 2048
  374.    unique IP addresses and more than 1024 would be assigned 8 contiguous
  375.    class C network numbers from the number space reserved for European
  376.    networks, 194.0.0.0 - 195.255.255.255.  If an organization from
  377.    Central America required fewer than 512 unique IP addresses and more
  378.    than 256, it would receive 2 contiguous class C network numbers from
  379.    the number space reserved for Central/South American networks,
  380.    200.0.0.0 - 201.255.255.255.
  381.  
  382.    The IR or the registry to whom the IR has delegated the registration
  383.    function will determine the number of Class C network numbers to
  384.    assign to a network subscriber based on the subscriber's 24 month
  385.    projection of required end system addresses according to the
  386.    following criteria:
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Gerich                                                          [Page 7]
  395.  
  396. RFC 1466     Guidelines for Management of IP Address Space      May 1993
  397.  
  398.  
  399.            Organization                            Assignment
  400.  
  401.    1) requires fewer than 256 addresses    1 class C network
  402.    2) requires fewer than 512 addresses    2 contiguous class C networks
  403.    3) requires fewer than 1024 addresses   4 contiguous class C networks
  404.    4) requires fewer than 2048 addresses   8 contiguous class C networks
  405.    5) requires fewer than 4096 addresses  16 contiguous class C networks
  406.    6) requires fewer than 8192 addresses  32 contiguous class C networks
  407.    7) requires fewer than 16384 addresses 64 contiguous class C networks
  408.  
  409.    If the subscriber's network is divided into logically distinct LANs
  410.    across which it would be difficult to use the given number of Class C
  411.    network numbers, the above criteria may apply on a per-LAN basis.
  412.    For example, if a subscriber has 600 hosts equally divided across ten
  413.    Ethernets, the allocation to that subscriber could be ten Class C
  414.    network numbers; one for each Ethernet. The subscriber would have to
  415.    support the request with to deviate from the stated criteria with an
  416.    engineering plan.
  417.  
  418.    These criteria are not intended to cause a subscriber to subnet Class
  419.    C networks unneccessarily.  Although, if a subscriber has a small
  420.    number of hosts per subnet, the subscriber should investigate the
  421.    feasibility of subnetting Class C network numbers rather than
  422.    requesting one Class C network number for every subnet.  In cases
  423.    where the lack of Class C subnetting would result in an extravagant
  424.    waste of address space, the registries may request an engineering
  425.    plan detailing why subnetting is impossible.
  426.  
  427.    If a subscriber has a requirement for more than 4096 unique IP
  428.    addresses it could conceivably receive a Class B network number.
  429.    However, there are cases where a subscriber may request a larger
  430.    block of Class C network numbers. For instance, if an organization
  431.    requires fewer than 8192 addresses and requests 32 Class C network
  432.    addresses, the regional registry may honor this request.  The maximal
  433.    block of Class C network numbers that should be assigned to a
  434.    subscriber consists of 64 contiguous Class C networks. This would
  435.    correspond to a single IP prefix of 18 bits.
  436.  
  437.    Exceptions from the above stated criteria will be determined on a
  438.    case-by-case basis.
  439.  
  440. 5.0  Conclusion
  441.  
  442.    This proliferation of class C network numbers may aid in retarding
  443.    the dispersion of class A and B numbers, but it is sure to accelerate
  444.    the explosion of routing information carried by Internet routers.
  445.    Inherent in these recommendations is the assumption that there will
  446.    be modifications in the technology to support the larger number of
  447.  
  448.  
  449.  
  450. Gerich                                                          [Page 8]
  451.  
  452. RFC 1466     Guidelines for Management of IP Address Space      May 1993
  453.  
  454.  
  455.    network address assignments due to the decrease in assignments of
  456.    Class A and B numbers and the proliferation of Class C assignments.
  457.  
  458.    Many proposals have been made to address the rapid growth of network
  459.    assignments and a discussion of those proposals is beyond the scope
  460.    and intent of this paper.
  461.  
  462.    These recommendations for management of the current IP network number
  463.    space only profess to delay depletion of the IP address space, not to
  464.    postpone it indefinitely.
  465.  
  466. 6.0  Acknowledgements
  467.  
  468.    The author would like to acknowledge the substantial contributions
  469.    made by the members of the following two groups, the Federal
  470.    Engineering Planning Group (FEPG) and the Intercontinental
  471.    Engineering Planning Group (IEPG). This document also reflects many
  472.    concepts expressed at the IETF Addressing BOF which took place in
  473.    Cambridge, MA in July 1992. In addition, Dan Long (BBN), Jon Postel
  474.    (ISI), and Yakov Rekhter (T.J. Watson Research Center, IBM Corp.)
  475.    reviewed this document and contributed to its content. The author
  476.    thanks those groups and individuals who have been cited for their
  477.    comments.
  478.  
  479. 7.0  References
  480.  
  481.    [1] Cerf, V., "IAB Recommended Policy on Distributing Internet
  482.        Identifier Assignment and IAB Recommended Policy Change to
  483.        Internet 'Connected' Status", RFC 1174, CNRI, August 1990.
  484.  
  485.    [2] Wang, Z., and J. Crowcroft, "A Two-Tier Address Structure for the
  486.        Internet: A Solution to the Problem of Address Space Exhaustion",
  487.        RFC 1335, University College London, May 1992.
  488.  
  489. Other related relevant work:
  490.  
  491.    [3] "Internet Domain Survey", Network Information Systems Center, SRI
  492.        International, July 1992.
  493.  
  494.    [4] Solensky, F., and F. Kastenholz, "A Revision to IP Address
  495.        Classifications", Work in Progress, March 1992.
  496.  
  497.    [5] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Supernetting: an
  498.        Address Assignments and Aggregation Strategy", RFC 1338, BARRNet,
  499.        cisco, Merit, OARnet, June 1992.
  500.  
  501.    [6] Rekhter, Y., and  Li, T., "Guidelines for IP Address Allocation",
  502.        Work in Progress, August 1992.
  503.  
  504.  
  505.  
  506. Gerich                                                          [Page 9]
  507.  
  508. RFC 1466     Guidelines for Management of IP Address Space      May 1993
  509.  
  510.  
  511.    [7] Rekhter, Y. and Topolcic, C., "Exchanging Routing Information
  512.        across Provider/Subscriber boundaries in CIDR environment", Work
  513.        in Progress, February 1993.
  514.  
  515. 8.0 Security Considerations
  516.  
  517.    Security issues are not discussed in this memo.
  518.  
  519. 9.0 Author's Address
  520.  
  521.    Elise Gerich
  522.    Merit Network, Inc.
  523.    1071 Beal Avenue
  524.    Ann Arbor, MI 48109-2112
  525.  
  526.    Phone: (313) 936-3335
  527.    EMail: epg@MERIT.EDU
  528.  
  529.  
  530.  
  531.  
  532.  
  533.  
  534.  
  535.  
  536.  
  537.  
  538.  
  539.  
  540.  
  541.  
  542.  
  543.  
  544.  
  545.  
  546.  
  547.  
  548.  
  549.  
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Gerich                                                         [Page 10]
  563.